Talk:PC speaker sound effects

Hardcoded values
If you look at DOOM2.EXE v1.9 with a hex editor, you'll see at offset 0x89064 the beginning of a table of unsigned 16-bit LE values which correspond to the counter values. After the 128th value, there are several null bytes. This really looks like the table containing all the counter values that get programmed into the 8253 chip. This also shows that there are valid values above 95 -- the doc included with Andrew Apted & Simon Howard's specifications said that it "is not known if higher values are supported" -- I think this shows that they most certainly are. --Gez 18:40, 24 January 2014 (UTC)


 * The same table exists in strife1.exe v1.2 @ dseg03:0009A09C and is xref'd from a DMX subroutine at cseg01:0004BC79.Here is the code in the immediate vicinity of the access. --Quasar 07:04, 25 January 2014 (UTC)


 * On further research, that function is the function which does the actual output. It is invoked after setup code is run to initialize the global variables it accesses, which is in sub_4BD70. sub_4BD70 is invoked from SFX_PlayPatch when the DMX sample format byte is " < 1u" (DMX sample formats 1 and 2, which are unknown, are dispatched to sub_4C260; format 0x03, which we know to be the sound format, is dispatched to sub_48430, which I already did substantial reversing work on earlier). --Quasar 07:21, 25 January 2014 (UTC)

DMX formats 1 & 2
This is an interesting discovery by Alexey Khokholov: DMX sample formats 1 and 2 correspond to MIDI data! --Gez (talk) 13:28, 10 November 2015 (CST)


 * I knew at least one was considered as being for "AdLib" due to code that is present in the pre-beta, but I was never able to crack the DMX code doing the format reading for them because it devolved into a bunch of function pointer calls and a ton of data movement that I couldn't effectively trace. Interesting to have my suspicions confirmed. --Quasar (talk) 16:35, 10 November 2015 (CST)